|
|
|
|
|
|
|
The pivotal players or roles about which you'll be concerned in this chapter are the requirements gatherer, object-oriented analyst, and architect. |
|
|
|
|
|
|
|
|
The Requirements Gatherer |
|
|
|
|
|
|
|
|
As a requirements gatherer, you typically interrogate end users, business managers (or domain experts), project managers, or anyone else who has the misfortune of coming across your path. Usually, there is no predefined method for gathering these requirements; you simply draft an almost ad hoc list of questions centered on mouse clicks instead of business processes executed by users. A requirements model is never generated. However, as a requirements gatherer, that's exactly what you want to do. A requirements model captures all the ways the user will use the Visual Basic system you're developing. Figure 2.1 shows a typical requirements model. |
|
|
|
|
|
|
|
|
Figure 2.1.
A requirements model (the initial use-case model)
illustrates how the end user will use your system from a
business processing perspective. |
|
|
|
|
|
|
|
|
In gathering requirements, you ask both yourself and the user how the system will be used. Initial requirements-gathering activities should shy away from inquiries such as When you click such and such a button on the screen, what happens next? You're forcing the user to think like a machine instead of like a business process user. Requirements gathering centered on graphical user interface (GUI) objects focuses on the semantics of clicking controls and moving a mouse, as opposed to the business tasks that the user must accomplish. When centered on GUI objects, requirements gathering often misses the big picture, and the foundation for further analysis activities becomes inefficient as the project evolves. |
|
|
|
|
|
|
|
|
The Object-Oriented Analyst |
|
|
|
|
|
|
|
|
As analysts in a traditional project, some developers are probably driven by a simplified focus on making the gathered requirements fit into the Visual Basic project. They |
|
|
|
|
|
